fix(opencode): lastUser identification and loop exit condition#11443
fix(opencode): lastUser identification and loop exit condition#11443khj809 wants to merge 1 commit intoanomalyco:devfrom
Conversation
|
Thanks for your contribution! This PR doesn't have a linked issue. All PRs must reference an existing issue. Please:
See CONTRIBUTING.md for details. |
|
The following comment was made by an LLM, it may be inaccurate: Based on my search results, I found one potentially related PR: PR #7425: fix(session): sort messages by time.created instead of alphabetical order This PR appears to be addressing a similar issue - sorting messages by creation timestamp instead of alphabetical order. This relates directly to the first fix in PR #11443 where messages need to be sorted chronologically by the The other results (PRs #4710, #7756, #10123) are unrelated feature additions to session handling and don't appear to be duplicates of the specific bug fixes in the current PR. |
What does this PR do?
Fixed a bug where
lastUseris incorrectly identified in multi-turn situations and exits the loop prematurely without generating a response.In the below:
opencode/packages/opencode/src/session/prompt.ts
Lines 282 to 284 in f834915
msgsare traversed in reverse order, butmsgsis not guaranteed to be chronologically ordered. The loop then identifies the wronglastUserand the exit condition is incorrectly evaluated.Fix: Sort
msgsbycreatedtimestamp to ensure chronological orderChanged the loop exit condition from lexicographical ID comparison to a parent-child relationship check to prevent infinite loops.
In the below:
opencode/packages/opencode/src/session/prompt.ts
Lines 296 to 300 in f834915
lastUserandlastAssistantare correctly found, iflastUser.idis lexicographically higher thanlastAssistant.id, it does not break the loop and continues the steps infinitely.Fix: Change exit condition from ID comparison to
lastFinished.parentID === lastUser.id, which properly checks if the finished message is a response to the user messageHow did you verify your code works?
It was hard to reproduce the issue, since sometimes the conditions are evaluated as expected by chance. I tested a multi-turn conversation scenario several times by logging
msgsand the IDs of messages.